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Description 

Related Application Information 

[0001] This application claims the benefit of United 
States Provisional Patent Application Number 
60/191,278, filed March 22, 2000, and is a continuation 
of United States Patent Application No. 09/627,523, filed 
June 28, 2000. 

Technical Field 

[0002] The present invention relates to presence da- 
tabase services, and more particularly to the routing and 
processing of presence service related signaling mes- 
sages in a communications network. 

Background Art 

[0003] Instant messaging (IM), as it is currently known 
within the communications industry, is an Internet tech- 
nology that allows subscribers to send and receive text 
messages, voice messages and other data in near real- 
time. While IM started as a way to chat with friends, the 
technology has become an essential tool for many busi- 
nesses, as it offers the convenience of e-mail and the 
immediacy of a phone call, as well as file transfers and 
voice messaging. 

[0004] Instant messaging is possible because the peo- 
ple sending and receiving messages remain constantly 
connected to their IM service. Recipients get messages 
as fast as the data can travel across the Internet. Con- 
ventional e-mail, on the other hand, is less immediate. 
E-mail technology sends messages to a server that 
stores the items until they are downloaded by the recip- 
ient's e-mail software. Many industry experts argue that 
it is the "instant" or near real-time communication char- 
acteristic that has made and will continue to make IM a 
mode of communication in the future. 
[0005] At present, when a subscriber logs in to an IM 
service, the subscriber's software notifies a presence 
server or similar client based presence system that the 
subscriber is available to receive messages. Such a sce- 
nario is generally illustrated in Figure 1. Once the sub- 
scriber is logged in or "registered," the subscriber can 
choose to send a message to another online user. From 
a network communication perspective, such a commu- 
nication is accomplished via the sending of data packets 
containing address and user-type information to the in- 
tended recipient. Depending on which service is used, a 
server either directly relays the message to the recipient 
or facilitates a direct connection between the sender of 
a message and the recipient. In Figure 1 , communication 
between IM clients 100 is facilitated by presence server 
102. In order to communicate with other instant message 
clients, subscribers send registration messages to pres- 
ence server 1 02. The registration messages may contain 
contact information for IM clients 102. A proposed pres- 



ence protocol for performing registration and subscrip- 
tion services will be discussed in more detail below. 
[0006] IM services typically employ one of three means 
to move messages around: acentralized network, a peer- 

5 to-peer connection, or a combination of both. In a cen- 
tralized setup, users are connected to each other through 
a series of data servers. Such servers effectively form a 
wide area network (WAN). Consequently, when an in- 
stant message is sent by a subscriber, at least one of the 

10 data servers finds the intended recipient's PC address 
and routes the message through the network until it 
reaches its destination. 

[0007] In the peer-to-peer approach, a central server 
maintains a database of online subscribers and their as- 
15 sociated Internet Protocol addresses. After a subscriber 
logs in, such a server sends the subscriber the IP ad- 
dresses of everyone on their contact list who is also cur- 
rently logged on. 

[0008] When a subscriber wishes to send an instant 
20 message to another user, the subscriber's client sends 
the IM directly to the user's client, without involving the 
server. As such, all IM message traffic does not neces- 
sarily go through the entire network. Such an architecture 
tends to result in improved network performance, as com- 
25 pared to other IM schemes. 

[0009] An excellent discussion of a proposed presence 
protocol can be found in an Internet Engineering Task 
Force (IETF) Internet Draft entitled, "The Presence Pro- 
tocol," internet-draft-saraswat-presenceprotocol-OO.txt, 
30 February 26, 1999. In the proposed presence protocol 
specification, a presence server is defined as a server 
that manages presence information for a collection of 
entities, subscriptions to those entities, and their privacy 
restrictions. 

35 [001 0] Each server has an address at which presence 
messages may be delivered. Presence information is de- 
fined in the proposed presence server protocol specifi- 
cation as information such as presence status, current 
point- of presence (if any), idle time, etc., for an entity. 

40 As used herein, the term presence information refers to 
any information regarding an end useror entity, including, 
but not limited to: end user location, end user status, me- 
dia capabilities of a telephony gateway associated with 
the end user, end user directory number, end user IP 

45 address, etc. 

[001 1 ] An entity has control over publication of its pres- 
ence information. An entity is defined as the unit, e.g. a 
person, on whose behalf presence information is being 
maintained. Each entity has a unique handle. The identity 

50 of the presence server maintaining presence information 
for the entity can be determined from the handle. A handle 
is well known name for an entity. An example of a handle 
is pp://www. intercom. att.com/TyrantRana. Finally, a 
point of presence (PoP) is defined as a point of presence 

55 for an entity. If an entity is present, it is connected to one 
PoP. Each PoP has an address, e.g., an IP address and 
a port number, at which presence messages may be de- 
livered. 
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[001 2] A typical example of how the presence protocol 
may be used is as follows. An entity A connected to an 
endpoint E may subscribed through a presence server 
P to another entity B. When the status of B changes, P 
will notify E of the change in status of B, if B's privacy 
specifications allow. If P is unable to notify E, for instance, 
because E is unreachable, P marks E as absent and will 
subsequently not attempt to deliver to E until E reestab- 
lishes its presence. In addition, P may periodically ping 
an endpoint for current status information on the entities 
connected through that endpoint. Such a heartbeat from 
the presence server ensures that presence information 
stored at the server is current. 

[0013] Once presence information about an entity is 
delivered to an endpoint, the endpoint may directly con- 
tact the entity. Protocols for exchanging instant messag- 
es, file transfer, etc. between two such endpoints are not 
defined in the above-referenced presence protocol spec- 
ification. Similarly, the protocol used for communication 
between clients and PoPs is outside the scope of the 
presence protocol specification. In addition, the transport 
protocol used to deliver presence messages including 
presence registration and update messages is not de- 
fined in the presence protocol specification. 
[001 4] One thing that the presence protocol specifica- 
tion does specify is message types used to perform pres- 
ence-related actions. It is these message types that may 
be sent by a presence server to update and obtain pres- 
ence information from a presence database. The mes- 
sage types include an assert message, which is sent by 
a PoP whenever the presence information associated 
with an entity changes. A fetch message is a request sent 
to the presence server to obtain presence information 
regarding a target specified in the fetch message. A sub- 
scribe message is a message sent to the presence server 
to allow the subscriber to receive presence information 
updates regarding a target specified in the subscribe 
message. A notify message is a message sent by the 
presence server to a requestor or a subscriber to convey 
presence information about a named entity. 
[0015] There are currently models, including the mod- 
els described above, that provide for instant messaging 
(IM) andpresence services within the scope of an Internet 
Protocol / data network environment. It will be appreci- 
ated from the discussion above that one of the key ele- 
ments of IM operation involves the ability for one sub- 
scriber to "know" when another subscriber is logged in 
or is "available." From the discussion above, it will also 
be appreciated that the ability to track the login status, 
otherwise known as "presence," of Internet users is fairly 
well developed and widely practiced. However, as com- 
munication networking technology has continued to 
evolve at a rapid pace, so have the means by which end 
users or subscribers can communicate. More particular- 
ly, the explosive growth of hand-held, wireless commu- 
nication terminals, such as cell phones, wireless WEB 
phones, and personal digital assistants has led to a de- 
mand for inter-networking or inter-medium communica- 



tion solutions. In otherwords, it is rapidly becoming useful 
for a subscriber to have their wireless phone status or 
"presence" known to other subscribers, where these oth- 
er subscribers may be using a variety of communication 
5 mediums, such as wireless phone service, wired phone 
service, short message service (SMS), or Internet serv- 
ice. 

[001 6] At present, such data network-based presence 
models do not address the implementation of these serv- 

10 ices within a traditional Public Switched Telephone Net- 
work (PSTN) environment. Again, with the continuing 
movement towards the convergence of data and teleph- 
ony networks, there exists the need to provide a system 
and method of enabling instant messaging and presence 

15 services in a communications environment that includes 
components of both traditional data and traditional te- 
lephony networks. Therefore, what is needed is an in- 
stant messaging / presence model for use in a converged 
data and telephony network. 

20 [001 7] Document WO 01 /56308A2 describes a system 
and method for sharing user event information among 
mobile (wireless) devices and those connected to fixed 
I P networks such as the Internet. The system and method 
support instant messaging between wireless devices and 

25 fixed IP network devices and between wireless devices 
and other wireless devices. The term wireless device is 
used broadly to include cell phones, laptop computers 
with wireless modems, wireless PDAs, and any other re- 
mote wireless devices. 

30 

Disclosure of the Invention 

[0018] This need is met by a method with the features 
of claim 1 and/or by a presence registration and routing 
35 node of claim 2 and/or by a computer program product 
of claim 15. 

[0019] According to one embodiment, the present in- 
vention includes a presence registration and routing 
node. The presence registration and routing node re- 

^0 ceives a signaling system 7 (SS7) message in response 
to a telephony-related action, such as the activation of a 
mobile handset, the dialing of a directory number to es- 
tablish a call, or the entry of predetermined DTMF digits. 
In response to the SS7 message, the presence registra- 

45 tion and routing node formulates a presence-server-com- 
patible message for updating presence information re- 
garding an end user in a presence-server-compatible for- 
mat, including session initiation protocol (SIP), presence, 
and Instant messaging and presence protocol (IMPP). 

50 SIP is defined in RFC 2543, SIP: Session Initiation Pro- 
tocol (March 1 999). IMPP is defined in RFC 2778, A Mod- 
el for Instant Messaging, (February 2000) and in RFC 
2779: Instant Messaging / Presence Protocol Require- 
ments (February 2000). Presence is defined in a variety 

55 of documents, including the IETF Internet draft men- 
tioned above and other IETF documents that will be dis- 
cussed below. The present invention is not intended to 
be limited to any specific presence protocol format. The 
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formats discussed herein are examples of presence pro- 
tocol formats suitable for use with the present invention. 
[0020] According to another embodiment, a presence 
registration and routing node includes an advanced da- 
tabase communications module (ADCM) for receiving 5 
queries for presence information. The ADCM module for- 
wards the queries to a presence application, such as a 
SIP, IMPP, or presence application. The presence appli- 
cation formulates a presence-server-compatible mes- 
sage, forwards the presence-server-compatible mes- 10 
sage to a presence database, receives a response from 
the database, and forwards the response to the ADCM 
module to be sent to the requestor over an IP network. 
The presence database may be internal or external to 
the presence registration and routing node. 15 
[0021 ] Some aspects of the invention will be explained 
in terms of modules and processes. It is understood that 
these modules or processes may be implemented in 
hardware, software, or a combination of hardware and 
software. Exemplary hardware upon which the process- 20 
es and modules described below may execute includes 
a microprocessor, such as an Intel Pentium® processor 
and associated memory. Each of the modules in a pres- 
ence registration and routing node according to the 
present invention may be a printed circuit board with a 25 
microprocessor and memory located thereon. The mi- 
croprocessor may execute one or more computer pro- 
grams for performing the presence registration and rout- 
ing functions discussed below. 

[0022] Accordingly, it is an object of the present inven- 30 
tion to provide a presence registration and routing node 
for receiving SS7 messages in response to telephony- 
related actions and formulating presence-server-com- 
patible messages in response to the SS7 messages. 
[0023] It is another object of the present invention to 35 
provide a presence registration and routing node for re- 
ceiving Internet Protocol (I P) encapsulated SS7 messag- 
es in response to telephony-related actions and formu- 
lating presence-server-compatible messages in re- 
sponse to the SS7 messages. 40 
[0024] It is another object of the present invention to 
provide a presence registration and routing node capable 
of routing presence-server-compatible messages to a 
presence database and forwarding responses from the 
database over an IP network. 45 
[0025] It is another object of the present invention to 
provide a presence registration and routing node that in- 
cludes an internal or integrated presence database. 
[0026] It is another object of the present invention to 
provide a presence registration and routing node that is 50 
adapted to maintain accounting or billing information re- 
lated to presence database access. 

Brief Description of the Drawings 

55 

[0027] Preferred embodiments of the invention will 
now be explained with reference to the accompanying 
drawings of which: 



Figure 1 is a block diagram illustrating conventional 
presence and instant messaging message flow; 
Figure 2 is a block diagram of an SS7/IP gateway 
that may be modified to perform presence message 
processing according to embodiments of the present 
invention; 

Figure 3 isablockdiagramof a presence registration 
and routing node according to an embodiment of the 
present invention; 

Figure 4 isablockdiagramof a presence registration 
and routing node according to an embodiment of the 
present invention; 

Figures 5a and 5b are a flow chart illustrating exem- 
plary steps that may be performed by a presence 
registration and routing node in processing an IAM 
message according to an embodiment of the present 
invention; 

Figure 6 is a block diagram illustrating SCCP encap- 
sulation of an ISUP IAM message; 
Figure 7 is a flow chart illustrating exemplary steps 
that may be performed by a presence registration 
and routing node in processing a TCAP message 
according to an embodiment of the present inven- 
tion; 

Figure 8 is a block diagram illustrating the operation 
of a presence registration and routing node in a mo- 
bile telecommunications network according to an 
embodiment of the present invention; 
Figure 9 is a block diagram illustrating the operation 
of a presence registration and routing node in 
processing an IAM message according to an em- 
bodiment of the present invention; 
Figure 1 0 is a blockdiagram illustrating the operation 
of a presence registration and routing node for in 
processing a TCAP message according to an em- 
bodiment of the present invention; 
Figure 11 is a block diagram of a presence registra- 
tion and routing node including an internal presence 
database according to an embodiment of the present 
invention; 

Figure 1 2 is a flow chart illustrating exemplary steps 
that may be performed by the presence registration 
and routing node illustrated in Figure 1 1 in respond- 
ing to a presence query for updating presence infor- 
mation according to an embodiment of the present 
invention; 

Figure 1 3 is a block diagram of a presence registra- 
tion and routing node including an external presence 
database according to an embodiment of the present 
invention. 

Figure 1 4 is a block diagram of a presence registra- 
tion and routing according to an embodiment of the 
present invention that includes a message account- 
ing and billing subsystem; 

Figure 15 is a table that illustrates a sample usage 
and measurements database associated with a 
message accounting and billing subsystem of the 
present invention; and 
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Figure 1 6 is a block diagram of a presence registra- 
tion and routing according to an embodiment of the 
present invention that includes a presence database 
and message accounting and billing subsystem. 

Detailed Description of the Invention 

[0028] The present invention includes a presence reg- 
istration and routing (PRR) node for communicating with 
and routing messages between both Internet Protocol 
(IP) and Signaling System 7 (SS7) network nodes. In one 
embodiment, a PRR node employs an internal architec- 
ture similar to that of high performance STP and signaling 
gateway (SG) products which are marketed by Tekelec, 
Inc., of Calabasas, California as the Eagle® STP and IP 7 
Secure Gateway 1171 , respectively. A block diagram that 
generally illustrates the base internal architecture of the 
Eagle® STP product is shown in Figure 2. A detailed de- 
scription of the Eagle® STP may be found in the Eagle® 
Feature Guide PN/91 0-1225-01 , Rev. B, January 1998, 
published by Tekelec, the disclosure of which is incorpo- 
rated herein by reference in its entirety. Similarly, a de- 
tailed description of the IP 7 Secure Gateway tm may be 
found in Tekelec publication PN/909-0767-01 , Rev B, Au- 
gust 1 999, entitled Feature Notice IP 7 Secure Gateway*™ 
Release 1.0. The specific functional components of an 
IP 7 Secure Gateway tm for transmitting and receiving 
TCAP messages over an Internet Protocol (IP) network 
are described in commonly-assigned, co-pending Inter- 
national Patent Publication No. WO 00/351 55, Published 
June 15, 2000. As described in the above referenced 
Eagle® Feature Guide, an Eagle® STP 250 includes the 
following subsystems: a Maintenance and Administration 
Subsystem (MAS) 252, a communication subsystem 254 
and an application subsystem 256. 
[0029] MAS 252 provides maintenance communica- 
tions, initial program load, peripheral services, alarm 
processing and system disks. Communication subsys- 
tem 254 includes an Interprocessor Message Transport 
(IMT) bus that is the main communication bus among all 
subsystems in the Eagle® STP 250. This high-speed 
communications system functions as two 125 Mbps 
counter-rotating serial buses. 

[0030] Application subsystem 256 includes application 
cards that are capable of communicating with the other 
cards through the IMT buses. Numerous types of appli- 
cation cards can be incorporated into STP 250, including: 
a Link Interface Module (LIM) 258 that provides SS7 links 
and X.25 links and an Application Service Module (ASM) 
262 that provides global title translation, gateway screen- 
ing and other services. A Translation Service Module 
(TSM) 264 may also be provided to support triggered 
local number portability service. Once again, a detailed 
description of the Eagle® STP is provided in the above 
cited Eagle® Feature Guide and need not be described 
in detail herein. With particular regard to the signaling 
gateway (SG) product line produced by Tekelec, itshould 
also be appreciated that a Data Communication Module 



(DCM) 260 can be employed to provide for the transport 
of Internet Protocol (IP) encapsulated SS7 messages 
over an IP network, as described in the above referenced 
Feature Notice IP 7 Secure Gateway™ Release 1.0 pub- 

5 lication. With further regard to the TSM triggered LNP 
services module mentioned above, adetailed description 
of the Tekelec triggered LNP solution may be found in 
the Feature Guide LNP LSMS PN/91 0-1 598-01 , Rev. A, 
January 1998, published by Tekelec. Furthermore, sys- 

10 terns and methods for providing triggerless LNP function- 
ality within a network routing node are described in com- 
monly-assigned, co-pending U.S. Patent Application No. 
09/503,541, filed February 14, 2000. 

15 SS7 MSU Triggered Presence Registration Message 
Generation 

[0031] Shown in Figure 3 is a schematic diagram of a 
presence registration and routing node 300 of the present 

20 invention. It will be appreciated that presence registration 
and routing node 300 includes a high speed Interproc- 
essor Message Transport (IMT) communications bus 
310. Communicatively coupled to IMT bus 310 are a 
number of distributed processing modules or cards in- 

25 eluding: a pair of Maintenance and Administration Sub- 
system Processors (MASPs) 312, an SS7-capable Link 
Interface Module (LIM) 320, an I P-capable Advanced Da- 
ta Communication Module (ADCM) 360, and a Presence 
Registration Module (PRM) 340. These modules are 

30 physically connected to the IMT bus 310 such that sign- 
aling and other type messages may be routed internally 
between all active cards or modules. For simplicity of 
illustration, only a single LIM 320, ADCM 360, and PRM 
340 are included in Figure 3. However, it should be ap- 

35 predated that the distributed, multi-processor architec- 
ture of the presence registration and routing node 300 
facilitates the deployment of multiple LIM, ADCM, PRM, 
and other cards, all of which could be simultaneously 
connected to the IMT bus 310. 

40 [0032] MASP pair 312 implements the maintenance 
and administration subsystem functions described 
above. As the MASP pair 31 2 are not particularly relevant 
to a discussion of the flexible routing attributes of the 
present invention, a detailed discussion of their function 

45 is not provided herein. For a comprehensive discussion 
of additional MASP operations and functionality, the 
above-referenced Tekelec publications can be consult- 
ed. 

[0033] Focusing now on LIM card functionality, it will 
50 be appreciated that LIM 320 is comprised of a number 
of sub-component processes including, but not limited 
to; an SS7 MTP level 1 process 322, an SS7 MTP level 
2 process 324, an I/O buffer or queue 325, a gateway 
screening (GWS) process 326, a Presence Registration 
55 Request (PRR) stop action process 328, an SS7 MTP 
level 3 layer HMDC process 330, and an HMDT process 
332. MTP level 1 and 2 processes 322 and 324, respec- 
tively, provide the facilities necessary to send and receive 
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digital data over a particular physical media / physical 
interface, as well as to provide error detection / correction 
and sequenced delivery of all SS7 message packets. I/O 
queue 325 provides for temporary buffering of incoming 
and outgoing signaling message packets. GWS process 
326 is responsible for examining the incoming signaling 
message and determining which, if any, of the provi- 
sioned stop actions are applicable. PRR stop action proc- 
ess 328 is responsible for making a copy of, and subse- 
quently encapsulating, an incoming SS7 ISDN User Part 
(ISUP) IAM signaling message packet within an SS7 Sig- 
naling Connection Control Part (SCCP) formatted pack- 
et. It should be appreciated that PRR stop action process 
328 could also be configured to simply encapsulate the 
original incoming SS7 ISUP IAM signaling message, 
without making a copy. MTP level 3 HMDC process 330 
receives signaling messages from the lower processing 
layers and performs a discrimination function, effectively 
determining whether an incoming SS7 message packet 
requires internal processing or is simply to be through 
switched. For instance, in the case of an SS7 TCAP mes- 
sage associated with presence registration or an SCCP 
encapsulated ISUP IAM message, HMDC process 330 
would determine that the message should be internally 
routed for further processing. HMDT process 332 man- 
ages or directs the internal routing of SS7 message pack- 
ets that require additional processing prior to final routing. 
Once again, it should be appreciated that a LIM card may 
contain more functional processes than those described 
above. The above discussion is limited to LIM function- 
ality associated with the basic processing of in-bound 
signaling messages. 

[0034] As such, it will be appreciated that the three 
functional processes associated with an Advanced Data 
Communications Module (ADCM) 360 shown in Figure 
3 are simply those processes that are relevant to a dis- 
cussion of out-bound ADCM operation in the examples 
of PS routing node operation disclosed herein. Further- 
more, it will be appreciated that ADCM 360 is similar in 
function to the DCM application module described above. 
In the case of ADCM 360, the message packets proc- 
essed by the card need not be native SS7 type messages 
that have been encapsulated in an IP packet. Instead, 
the ADCM 360 is capable of processing, transmitting, 
and receiving both native SS7 and native IP protocol 
messages. 

[0035] The processes explicitly shown on the out- 
bound ADCM 360 include an I/O queue 362 and I P level 
1 and 2 processes 366 and 364, respectively. I/O queue 
362 facilitates temporary buffering of incoming and out- 
going signaling message packets, while IP addressing 
operations are performed by the IP level 1 and 2 proc- 
esses 366 and 364, respectively. 
[0036] Once again, the description of LIM and ADCM 
sub-components provided in the above description is lim- 
ited to those sub-components that are relevant to the 
sample implementation scenarios discussed herein. For 
a comprehensive discussion of additional LIM and AD- 



CM-type operations and functionality, the above-refer- 
enced Tekelec publications can be consulted. 
[0037] In general, a PRM card includes the database 
and database control processes necessary to achieve 

5 the presence registration message generation and rout- 
ing functionality of the present invention. The PRM 340 
shown in Figure 3 is comprised, in part, of an SCCP sub- 
system controller known as a Signaling Connection Rout- 
ing Controller (SCRC) process 342, a Presence Regis- 

10 tration Manager (PRMG) process 344, and a number of 
Presence Registration Applications generally indicated 
by the numeral 346. Included among the Presence Reg- 
istration Applications is a session initiation protocol (SIP) 
registration application process 348 for generating SIP 

15 messages, forwarding the SIP messages to a presence 
server, and processing SIP messages received from the 
presence server. The format for SIP messages is de- 
scribed in detail in the above-referenced RFC 2543, 
which defines the SIP protocol. In addition, the portion 

20 of a SIP message that carries the media capabilities in- 
formation for an end user device is referred to as the 
session description protocol portion. The session de- 
scription protocol is described in detail in RFC 2327, 
"SDP: Session Description Protocol," (April 1998). 

25 [0038] Presence protocol process 349 may also be in- 
cluded for communicating with a presence server using 
the messages described in the above-referenced pres- 
ence protocol specification. 

[0039] Instant messaging and presence protocol (IM- 
30 PP) process 351 may also be included forcommunicating 
with a presence server according to the IMPP protocol. 
The IMPP protocol is described in detail above and in 
one or more of the following IETF Internet Draft docu- 
ments: 

35 

"Message Information Data Format," <draft-ietf-im- 
pp-midf-01 .txt>, January 19, 2000; 
"Presence Information Data Format for IMPP," 
<draft-ietf-impp-pidf-01.txt>, March 10, 2000; and 
40 "Transport Protocol for Presence Information/ In- 
stant Messaging," <draft-ietf-impp-pitp-mitp-01 >, 
March 9, 2000, 

the disclosures of each of which are incorporated herein 

45 by reference in their entirety. 

[0040] The present invention is not limited to commu- 
nicating with a presence server using SIP, IMPP, or pres- 
ence protocols. Any protocol for communicating with a 
presence server is within the scope of the invention. 

50 [0041] SCRC process 342 is responsible for discrimi- 
nation of signaling messages at the SCCP level, and for 
distributing the signaling messages to an appropriate 
higherprocessing level application orfunction. Inthecon- 
figuration shown in Figure 3, the next highest processing 

55 level is represented by the PRMG process 344. PRMG 
process 344 is responsible for determining how to proc- 
ess the incoming message packet. For instance, if the 
message packet contains an SCCP encapsulated ISUP 
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IAM message, PRMG process 344 is configured to en- 
capsulate the original ISUP IAM message, and subse- 
quently extract the appropriate information necessary for 
further processing from the de-capsulated message. 
However, if the incoming message were a TCAP format- 
ted packet, no de-capsulation action would be required. 
In either case, PRMG process 344 is also charged with 
determining which of the provisioned presence registra- 
tion applications is required for successful processing of 
a particular incoming signaling message packet. As will 
be appreciated from Figure 3, a number of presence reg- 
istration applications may be simultaneously provisioned 
on a single PRMG card. These presence registration ap- 
plications may be configured such that each application 
is capable of generating presence registration messages 
that are formatted in different protocols including, but not 
limited to, SIP, IMPP, and presence protocol. 
[0042] While any of the above-described presence 
registration applications may be provisioned on a single 
PRM card, SIP registration application 348 is used in the 
examples described herein to illustrate the functionality 
of the presence registration and routing node in updating 
presence information in a presence server database and 
obtaining presence information. SIP registration applica- 
tion 348 essentially contains the logic necessary to proc- 
ess the incoming SS7 message and construct the appro- 
priate SIP-formatted presence registration message. 
[0043] Shown in Figures 3 and 4 are system level di- 
agrams of one embodiment of presence registration and 
routing node 300 of the present invention. Also indicated 
in both figures are general message flows associated 
with the processing of incoming SS7 signaling packets 
and the generation of outbound presence registration 
messages. More particularly, Figure 3 illustrates the mes- 
sage flow associated with an incoming SS7 ISUP IAM 
message, while Figure 4 indicates the message flow as- 
sociated with an incoming SS7 TCAP message. A de- 
tailed flow chart of the major steps associated with one 
particular implementation of the SS7 triggered presence 
registration message generation process is presented in 
Figures 5a and 5b, and may be used in conjunction with 
the schematic diagram shown in Figure 3 to better un- 
derstand the ISUP IAM based presence registration mes- 
sage generation methodology. 

[0044] Referring to Figure 5a, in step ST1 , an incoming 
ISUP IAM message is received at the inbound LIM mod- 
ule 320. In steps ST2 and ST3, the incoming ISUP IAM 
message is received and processed by the MTP Level 1 
and 2 processes 322 and 324, respectively. With MTP 
Level 1 and 2 processing complete, the signaling mes- 
sage packet is temporarily buffered in the I/O queue 325 
before being passed up the stack to the MTP Level 3 
Gateway Screening (GWS) process 326. As indicated in 
step ST4, GWS process 326 examines the incoming IS- 
UP IAM message and determines not only whether the 
message is to be allowed into the switch for further 
processing, but also which, if any, of the provisioned stop 
actions are applicable to the incoming message. In this 



example, GWS process 326 examines the incoming IS- 
UP IAM message and determines that the message is 
permitted to enter the switch. Furthermore, upon exam- 
ination of the Originating Point Code (OPC), Destination 

5 Point Code (DPC) and Service Indicator Octet (SIO) 
fields contained in the MTP routing layer, it is determined 
that the message requires additional processing by the 
P R R stop action 328 (ST5). I n steps ST6 P R R stop action 
process 328 receives the ISUP IAM message from GWS 

10 process 326 and determines that the incoming message 
is an ISUP type MSU. The PRR stop action process 328 
next checks the DPC of the incoming MSU. More spe- 
cifically, the PRR stop action verifies that the DPC of the 
incoming MSU is a valid PC. PRR stop action 328 exam- 
's ines the incoming MSU to determine whether presence 
registration service is required. If the incoming MSU is 
identified as being an ISUP IAM type message, PRR stop 
action 328 encapsulates a copy of the ISUP IAM mes- 
sage within an SCCP formatted MSU, as indicated in 

20 step ST6. Such SCCP encapsulation is effectively 
achieved by adding essential SCCP message leading 
and trailing bit sequences to the base bit sequence that 
comprises the ISUP IAM MSU, as generally illustrated in 
Figure 6. Thus, an SCCP type encapsulated MSU is cre- 

25 ated which envelops or contains an ISUP type MSU. Sub- 
sequent to this encapsulation, the incoming message no 
longer appears or is treated as an ISUP IAM message 
within the presence registration and routing node 300, 
but is instead processed internally as an SCCP type SS7 

30 message. 

[0045] Unless additional processing by an unrelated 
subsystem is required, the original ISUP IAM MSU is 
then routed directly to HMDC process 330 where normal 
ISUP MSU type routing is resumed. However, once 

35 again, it should be appreciated that the original ISUP IAM 
MSU could be SCCP encapsulated and further proc- 
essed instead of producing a copy of the ISUP MSU. It 
should also be appreciated that failure of the incoming 
ISUP MSU to meet the criteria specified in step causes 

40 the original, non-encapsulated MSU to be routed directly 
to HMDC process 330 where normal ISUP MSU type 
routing is resumed. 

[0046] However, in the case where an incoming ISUP 
MSU satisfies the ST5 criteria, SCCP encapsulation of 

45 the ISUP MSU occurs and the resulting encapsulated 
MSU is directed to HMDC process 330 (ST7), where SC- 
CP type processing is performed. In the example shown 
in Figure 3, HMDC process 330 examines the message 
packet and determines that the DPC and Subsystem 

50 Number (SSN) of the SCCP packet is the PC of the pres- 
ence registration and routing node. Consequently, fur- 
ther processing of the SCCP MSU within the routing node 
is assumed to be necessary, and the packet is passed 
to the HMDT process 332. The HMDT process 332 ex- 

55 amines the Service Indicator (SI) field of the encapsulat- 
ed MSU, which indicates that the encapsulating packet 
is of an SCCP type. As such, HMDT process 332 places 
the encapsulated SCCP MSU on high speed IMT bus 
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31 0 for transport to PRM 340 and subsequent presence 
registration service. 

[0047] Referring to Figure 5b, in step ST8, the encap- 
sulated SCCP MSU is received and examined by SCRC 
process 342 that is resident on PRM 340. SCRC process 
342 examines the message, determines that presence 
registration service is indicated, and forwards the encap- 
sulated MSU to the PRMG process 344, as indicated by 
step ST9. In step ST10, PRMG process 344 extracts the 
ISUP IAM MSU from the SCCP envelope and determines 
that the ISUP MSU requires the generation of a SlP-for- 
matted presence registration message (ST1 1). The ISUP 
IAM MSU is subsequently directed to SIP application 348 
for further processing (ST12). SIP application 348 exam- 
ines the ISUP IAM MSU and, using information contained 
within the MSU, generates a SIP-formatted presence 
registration message (ST13). 

[0048] With SIP processing complete, the SIP-format- 
ted presence registration message is passed to HMRT 
process 350. HMRT process 350 determines to which 
ADCM card the SIP registration message packet should 
be routed for subsequent outbound transmission (ST1 4). 
In this case, the HMRT process 350 determines that the 
desired outbound signaling link associated with the rout- 
ing of the SIP registration message is located on ADCM 
360. Consequently, the SIP message packet is internally 
routed across the IMT bus 310 to LIM 360, where it is 
received by the I/O queue process 362 (ST15). Eventu- 
ally, the modified message packet is passed from the I/O 
queue 362 on to the IP Level 2 and Level 1 processes 
364 and 366, respectively (ST16). Once again, IP level 
1 and 2 processes 366 and 364, respectively, provide 
the facilities necessary to send and receive digital data 
over a particular physical media / physical interface, as 
well as to provide error detection / correction and se- 
quenced delivery of all IP message packets transmitted 
into the IP network. As indicated in step ST17, the SIP- 
formatted presence registration message is then trans- 
mitted into an IP network for ultimate delivery to and use 
by a presence database system. 

[0049] It will be appreciated that the registration mes- 
sage generation methodology shown in Figure 4 is fun- 
damentally similar to the process indicated in Figures 5a 
and 5b. The primary difference involves processing var- 
iations that result from the handling of SS7 ISUP versus 
SS7 TCAP type messages. Most notably, since a TCAP 
message is, in fact, also an SCCP message, there is no 
need to directly encapsulate or copy and encapsulate 
the incoming TCAP message. Instead the TCAP mes- 
sage is simply directed from the inbound LIM 320 to the 
associated PRM 340 via the high speed IMT Bus 310, in 
muchthesame manner as the SCCP encapsulated ISUP 
IAM described in detail above. As such, Figure 7 presents 
a flow chart of the major steps associated with the 
processing of aTCAP-type presence registration request 
message, which may be used in conjunction with the 
schematic diagram shown in Figure 4 to better under- 
stand the TCAP based presence registration message 



generation methodology. 

[0050] With particular regard to the scenario generally 
illustrated in Figure 4, an incoming TCAP-formatted pres- 
ence registration request message is received at the in- 

5 bound LIM module 320 (ST1). Once again, in steps ST2 
and ST3, the incoming TCAP message is received and 
processed by the MTP Level 1 and 2 processes 322 and 
324, respectively. With MTP Level 1 and 2 processing 
complete, the signaling message packet is temporarily 

10 buffered in the I/O queue 325 before being passed up 
the stack to the MTP Level 3 Gateway Screening (GWS) 
process 326. As indicated in step ST4, GWS process 
326 examines the incoming TCAP message and deter- 
mines not only whether the message is to be allowed into 

15 the switch for further processing, but also which, if any, 
of the provisioned stop actions are applicable to the in- 
coming message. In the scenario shown in Figure 4, 
GWS process 326 examines the incoming TCAP mes- 
sage and determines that the message is permitted to 

20 enter the switch. Furthermore, upon examination of the 
Originating Point Code (OPC), Destination Point Code 
(DPC) and Service Indicator Octet (SIO) fields contained 
in the MTP routing layer, it is determined that the mes- 
sage does not require additional processing by the PRR 

25 stop action 328. As such, the TCAP MSU is then routed 
directly to HMDC process 330 where SCCP type 
processing is performed (ST5). In the example shown in 
Figure 4, HMDC process 330 examines the message 
packet and determines that the DPC and Subsystem 

30 Number (SSN) of the TCAP packet is the PC of the pres- 
ence registration and routing node. Consequently, fur- 
ther processing of the TCAP MSU within the routing node 
is assumed to be necessary, and the packet is passed 
to the HMDT process 332. The HMDT process 332 ex- 

35 amines the Service Indicator (SI) field of the TCAP MSU, 
which indicates that the packet is of an SCCP type. As 
such, HMDT process 332 places the TCAP MSU on high 
speed IMT bus 310 for transport to PRM 340 and sub- 
sequent presence registration service. 

^0 [0051] In step ST6, the TCAP MSU is received and 
examined by SCRC process 342 that is resident on PRM 
340. SCRC process 342 examines the message, deter- 
mines that presence registration service is indicated, and 
forwards the TCAP MSU to the PRMG process 344. As 

45 indicated in step ST7, the content of the TCAP message 
is examined to determine whether the TCAP presence 
registration request requires the generation of a SIP-for- 
matted message. In this example, it is assumed that the 
TCAP registration request message requires a SlP-for- 

50 matted response and as such, is subsequently directed 
to SIP application 348 for further processing. SIP appli- 
cation 348 examines the TCAP MSU and, using informa- 
tion contained within the MSU, generates a SIP-format- 
ted presence registration message (ST8). 

55 [0052] With SIP processing complete, the SIP-format- 
ted presence registration message is passed to HMRT 
process 350. HMRT process 350 determines to which 
ADCM card the SIP registration message packet should 
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be routed for subsequent outbound transmission (ST9). 
In this case, the HMRT process 350 determines that the 
desired outbound signaling link associated with the rout- 
ing of the SIP registration message is located on ADCM 
360. Consequently, the SIP message packet is internally 
routed across the IMT bus 310 to LIM 360, where it is 
received by the I/O queue process 362 (ST10). Eventu- 
ally, the modified message packet is passed from the I/O 
queue 362 on to the IP Level 2 and Level 1 processes 
364 and 366, respectively (ST11). As indicated in step 
ST12, the SIP-formatted presence registration message 
is then transmitted into an IP network for ultimate delivery 
to and use by a presence database system. 
[0053] Shown in Figures 8, 9 and 1 0 are simplified net- 
work diagrams that illustrate example implementations 
of the embodiments described above. More particularly, 
Figure 8 illustrates an implementation of the presence 
registration and routing node 300 of the present invention 
in a mobile or wireless telecommunications environment, 
generally indicated by the numeral 400. Network 400 in- 
cludes a mobile subscriber 402, a base station complex 
404, a mobile switching center (MSC) 406, a home loca- 
tion register (HLR) 408, and a presence server 410. It 
will be appreciated that the message flows shown in Fig- 
ure 8 indicate that the presence registration and routing 
node 300 formulates and transmits a presence registra- 
tion message 416 in response to the receipt of a location 
update message 412 that is sent from the MSC 406. 
Those skilled in the art of wireless telecommunications 
will appreciate that an MSC performs a number of func- 
tions in a wireless network, including the formulation and 
routing of signaling messages. In the example shown in 
Figure 8, the location update signaling message used by 
the presence registration and routing node 300 to trigger 
the presence registration message 416 is destined for 
the HLR node 408. In such a wireless scenario, the pres- 
ence registration message 416 could be formulated and 
transmitted by the presence registration and routing node 
in response to a mobile location update message asso- 
ciated with the registration of a wireless customer in a 
particular cell or service area. Once again, those skilled 
in the art of wireless or mobile telecommunications will 
appreciate that wireless or mobile signaling messages 
are generated and transmitted within a wireless network 
in response to the powering-up or turning-on of a cus- 
tomer's wireless phone, as well as in response to inter- 
cell movement of a mobile subscriber during the course 
of a mobile call. As such, the presence registration and 
routing node of the present invention facilitates a method 
of presence registration that is completely transparent to 
the cell or mobile phone user. 

[0054] Figure 9 illustrates an implementation of the 
presence registration and routing node 300 of the present 
invention in a wired telecommunications environment, 
generally indicated by the numeral 420. Network 420 in- 
cludes a wireline subscriber 422, an end office (EO) 424, 
and a presence server 426. It will be appreciated that the 
message flows shown in Figure 9 indicate that the pres- 



ence registration and routing node 300 formulates and 
transmits a presence registration message 434 in re- 
sponse to the receipt of an ISUP call signaling message 
from the EO 424. More particularly, the presence regis- 

5 tration message 434 is generated in response to the re- 
ceipt of an ISUP Initial Address Message (IAM) message 
428. Those skilled in the art SS7 signaling will appreciate 
that an ISUP IAM message is the first in a sequence of 
ISUP formatted SS7 call control signaling messages that 

10 are required to complete a phone call in the Public 
Switched Telephone Network (PSTN). As such, it will be 
appreciated that in the scenario illustrated in Figure 9, 
the presence registration message 434 is formulated in 
response to an attempt by the wireline subscriber 422 to 

15 place atelephone call. As presence registration message 
generation is triggered by an ISUP IAM message, it will 
be appreciated by those skilled in the art of SS7 telecom- 
munications that completion of an attempted telephone 
call is not required in order for a presence registration 

20 message to be generated and transmitted to a presence 
server. Thus, any call attempts by wireline subscriber 
422 will effectively register the subscriber's presence with 
presence server 426 via presence registration and rout- 
ing node 300 of the present invention. It will also be ap- 

25 predated from Figure 9, that the triggering ISUP IAM 
message 428 is subsequently routed as normal, on to a 
destination address specified in the message. 
[0055] Shown in Figure 1 0 is a variation of the scenario 
that was illustrated in Figure 9 whereby an SS7 signaling 

30 message used to trigger the formulation and subsequent 
transmission of a presence registration message is com- 
prised of a TCAP-type message instead of an ISUP-type 
message. Shown in Figure 10 is an implementation of 
the presence registration and routing node 300 of the 

35 present invention in a wired telecommunications envi- 
ronment, generally indicated by reference numeral 440. 
Network 440 includes a wireline subscriber 442, an end 
office (EO) 444, and a presence server 446. In the par- 
ticular embodiment shown in Figure 10, it is assumed 

40 that wireline subscriber 442 indirectly initiates a TCAP 
message 448 by dialing "*88" or a similar code on a tel- 
ephone keypad. Once again, those skilled in the art of 
SS7 telecommunication networks will appreciate that 
generation of such TCAP messages is accomplished by 

45 an End Office (EO) or Service Switching Point (SSP) in 
response to the "*88" keystrokes, as generally indicated 
in Figure 1 0. As such, by dialing "*88" wireline subscriber 
442 is effectively manually registering their presence with 
the presence server via the generation of the TCAP mes- 

50 sage 448, which in turn causes the generation of a pres- 
ence registration message 450 by the presence registra- 
tion and routing node 300 of the present invention. 

Integrated Presence Database System 

55 

[0056] The embodiments of the present invention de- 
scribed in detail above can be easily extended to include 
a presence registration and routing node that is capable 
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of maintaining a presence database system. One em- 
bodiment of such a presence registration and routing 
node is illustrated in Figure 11, and generally indicated 
by the numeral 500. It will be appreciated that in the par- 
ticular embodiment presently contemplated, presence 
registration messages are not formulated and routed 
from the node, but instead presence registration takes 
place at or within the node. That is, in the embodiment 
of the present invention shown in Figure 1 1 and generally 
discussed below, the functionality of a presence server 
is generally included within the presence registration and 
routing node 500. 

[0057] With particular regard to the embodiment illus- 
trated in Figure 1 1 and in a manner similar to the embod- 
iment described above, it will be appreciated that pres- 
ence registration and routing node 500 includes a high 
speed Interprocessor Message Transport (IMT) commu- 
nications bus 310. Communicatively coupled to IMT bus 
310 are a number of distributed processing modules or 
cards including: a pair of Maintenance and Administration 
Subsystem Processors (MASPs) 312, an SS7 capable 
Link Interface Module (LIM) 320, an I P capable Advanced 
Data Communication Module (ADCM) 360, and a Pres- 
ence Database Module (PDM) 502. These modules are 
physically connected to the IMT bus 310 such that sign- 
aling and other type messages may be routed internally 
between all active cards or modules. For simplicity of 
illustration, only a single LIM 320, ADCM 360, and PDM 
502 are included in Figure 1 1 . However, it should be ap- 
preciated that the distributed, multi-processor architec- 
ture of the presence registration and routing node 500 
facilitates the deployment of multiple LIM, ADCM, PDM, 
and other cards, all of which could be simultaneously 
connected to the IMT bus 310. 

[0058] As in the previously described embodiment, 
MASP pair 312 implement the overall maintenance and 
administration subsystem functions. For a comprehen- 
sive discussion of additional MASP operations and func- 
tionality, the above-referenced Tekelec publications can 
be consulted. 

[0059] Once again, it will be appreciated that LIM 320 
is comprised of a number of sub-component processes 
including, but not limited to: an SS7 MTP level 1 process 
322, an SS7 MTP level 2 process 324, an I/O buffer or 
queue 325, a gateway screening (GWS) process 326, a 
Presence Server Request (PRR) stop action process 
328, an SS7 MTP level 3 layer HMDC process 330, and 
an HMDT process 332. MTP level 1 and 2 processes 
322 and 324, respectively, provide the facilities neces- 
sary to send and receive digital data over a particular 
physical media / physical interface, as well as to provide 
error detection / correction and sequenced delivery of all 
SS7 message packets. I/O queue 325 provides for tem- 
porary buffering of incoming and outgoing signaling mes- 
sage packets. GWS process 326 is responsible for ex- 
amining the incoming signaling message and determin- 
ing which, if any, of the provisioned stop actions are ap- 
plicable. PRR stop action process 328 is responsible for 



making a copy of, and subsequently encapsulating, an 
incoming SS7 ISDN User Part (ISUP) IAM signaling mes- 
sage packet within an SS7 Signaling Connection Control 
Part (SCCP) formatted packet. It should be appreciated 

5 that PRR stop action process 328 could also be config- 
ured to simply encapsulate the original incoming SS7 
ISUP IAM signaling message, without making a copy. 
MTP level 3 HMDC process 330 receives signaling mes- 
sages from the lower processing layers and performs a 

10 discrimination function, effectively determining whether 
an incoming SS7 message packet requires internal 
processing or is simply to be through switched. For in- 
stance, in the case of an SS7 TCAP message associated 
with presence registration or an SCCP encapsulated IS- 

15 UP IAM message, HMDC process 330 would determine 
that the message should be internally routed for further 
processing. HMDT process 332 manages or directs the 
internal routing of SS7 message packets that require ad- 
ditional processing prior to final routing. Once again, it 

20 should be appreciated that a LIM card may contain more 
functional processes than those described above. The 
above discussion is limited to LIM functionality associat- 
ed with the basic processing of in-bound signaling mes- 
sages. 

25 [0060] As such, it will be appreciated that the three 
functional processes associated with Advanced Data 
Communication Module (ADCM) 360 shown in Figure 1 1 
are simply those processes that are relevant to a discus- 
sion of outbound ADCM operation in the examples of PS 

30 routing node operation disclosed herein. Furthermore, it 
will be appreciated that ADCM 360 is similar in function 
to the DCM application module described above. In the 
case of ADCM 360, the message packets processed by 
the card need not be native SS7 type messages that 

35 have been encapsulated in an IP packet. Instead, the 
ADCM 360 is capable of processing, transmitting, and 
receiving both native SS7 and native IP protocol mes- 
sages. 

[0061] The processes explicitly shown on the out- 

^0 bound ADCM 360 include an I/O queue 362 and IP level 
1 and 2 processes 366 and 364, respectively. I/O queue 
362 facilitates temporary buffering of incoming and out- 
going signaling message packets, while IP addressing 
operations are performed by IP level 1 and 2 processes 

45 366 and 364, respectively. 

[0062] Once again, the description of LIM and ADCM 
sub-components provided in the above description is lim- 
ited to those sub-components that are relevant to the 
sample implementation scenarios discussed herein. For 

50 a comprehensive discussion of additional LIM and AD- 
CM-type operations and functionality, the above-refer- 
enced Tekelec publications can be consulted. 
[0063] In general, a PDM card includes the database 
and database control processes necessary to facilitate 

55 the presence registration and query handling functional- 
ity of the contemplated embodiment of the present inven- 
tion. The PDM 502 shown in Figure 1 1 is comprised, in 
part, of an SCCP subsystem controller known as a Sig- 
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naling Connection Routing Controller (SCRC) process 
504, a Presence Database Manager (PDMG) process 
510, and a number of Presence Database Interface (PDI) 
Applications generally indicated by reference numeral 
512. Included among the PDI Applications 512 are ses- 
sion initiation protocol (SIP) application process 518, IM- 
PP application process 514, and presence protocol proc- 
ess 519. SCRC process 504 is responsible for discrimi- 
nation of signaling messages and subsequent distribu- 
tion of these signaling messages to an appropriate higher 
processing level application or function. In the configu- 
ration shown in Figure 11, the next highest processing 
level is represented by PDMG process 510. PDMG proc- 
ess 510 is generally responsible for determining which 
of the provisioned protocol-specific PDI Applications 512 
is required process the incoming message packet. For 
instance, if the incoming presence registration packet 
contained a TCAP or SCCP-encapsulated IMPP mes- 
sage, PDMG process 510 would determine that the pro- 
visioned PDI application 51 4 was required for successful 
processing. As will be appreciated from Figure 11, a 
number of PDI applications 512 may be simultaneously 
provisioned on a single PDMG card. These protocol-spe- 
cific PDI applications may be configured such that each 
application is capable of receiving presence registration 
or query messages that are formatted in different proto- 
cols including, but not limited to, SIP, IMPP, and the pres- 
ence protocol. Furthermore, these PDI applications 512 
are also capable of generating or formatting protocol- 
specific presence service related response messages. 
Such a presence service response message might in- 
clude, but is not limited to, a message that provides pres- 
ence status information for a specific user in response 
to a presence status query. This particular scenario is 
specifically illustrated in Figure 11, where the presence 
status query packet assumes the form of an SS7 TCAP- 
encapsulated IMPP query message and the subsequent 
presence status response is contained within a SIP for- 
matted message. 

[0064] Once again, while any number or variety of PDI 
applications may be provisioned on a single PDM card, 
only the IMPP, SIP, and presence protocol PDI applica- 
tions 514, 518, and 519, respectively, are described 
herein. SIP PDI application 518 essentially contains the 
logic necessary to process incoming SIP presence mes- 
sages and construct outgoing SIP presence response 
messages. Similarly, IMPP PDI application 51 4 contains 
the logic necessary to process incoming IMPP formatted 
presence messages and construct outgoing IMPP for- 
matted presence response messages. Presence PDI ap- 
plication 519 contains the logic necessary to process in- 
coming presence query messages formatted according 
to the presence protocol and construct outgoing pres- 
ence response messages formatted according to the 
presence protocol. 

[0065] Also included in Figure 1 1 is a general message 
flow associated with the processing of an incoming SS7 
TCAP-encapsulated IMPP formatted presence query 



message and the subsequent, related presence system 
processing activity. A detailed flow chart of the major 
steps associated with a TCAP-encapsulated IMPP pres- 
ence query scenario is presented in Figure 12, and may 

5 be used in conjunction with the schematicdiagram shown 
in Figure 1 1 to better understand the operation of pres- 
ence registration and routing node 500. 
[0066] With particular regard to the scenario generally 
illustrated in Figure 11, it is assumed that an incoming 

10 TCAP-encapsulated IMPP formatted presence query 
message is received at the inbound LIM module 320 
(ST1). Once again, in steps ST2 and ST3, the incoming 
TCAP-encapsulated IMPP formatted presence query 
message is received and processed by the MTP Level 1 

15 and 2 processes 322 and 324, respectively. With MTP 
Level 1 and 2 processing complete, the signaling mes- 
sage packet is temporarily buffered in the I/O queue 325 
before being passed up the stack to MTP Level 3 Gate- 
way Screening (GWS) process 326. As indicated in step 

20 ST4, GWS process 326 examines the incoming TCAP 
presence query message and determines not only 
whether the message is to be allowed into the switch for 
further processing, but also which, if any, of the provi- 
sioned stop actions are applicable to the incoming mes- 

25 sage. In the scenario shown in Figure 1 1 , GWS process 
326 examines the incoming TCAP-encapsulated IMPP 
presence query message and determines that the mes- 
sage is permitted to enter the switch. Furthermore, upon 
examination of the Originating Point Code (OPC), Des- 

30 tination Point Code (DPC) and Service Indicator Octet 
(SIO) fields contained in the MTP routing layer, it is de- 
termined that the message does not require additional 
processing by the PRR stop action 328. As such, the 
TCAP MSU is then routed directly to HM DC process 330 

35 where SCCP type processing is performed (ST5). In the 
example shown in Figure 1 1 , HMDC process 330 exam- 
ines the message packet and determines that the DPC 
and Subsystem Number (SSN) of the TCAP packet is 
the PC and SSN of the internal presence server database 

40 system that is located on PDM card 502. Consequently, 
further processing of the TCAP MSU within the routing 
node is assumed to be necessary, and the packet is 
passed to the HMDT process 332. The HMDT process 
332 examines the Service Indicator (SI) field of the TCAP 

45 MSU, which indicates that the packet is of an SCCP type. 
As such, HMDT process 332 places the TCAP MSU on 
high speed IMT bus 310 for transport to PDM 502 and 
subsequent presence database service. 
[0067] In step ST6, the TCAP MSU is received and 

50 examined by SCRC process 504 that is resident on PDM 
502. SCRC process 504 examines the message, deter- 
mines that presence database service is indicated, and 
forwards the TCAP MSU to the PDMG process 510. As 
indicated in step ST7, the message packet is examined 

55 to determine the protocol of the presence related mes- 
sage. In this case, the protocol of the presence related 
message encapsulated within the TCAP packet is IMPP. 
Next in step ST8 the variety or type of presence service 
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associated with the message is evaluated. Such general 
presence message types or varieties might include, but 
are not limited to, query and registration type messages. 
[0068] Once again, in this example, the IMPP-format- 
ted presence service message is a query message that 5 
is intended to extract information from a presence service 
database. As such, the IMPP formatted query message 
is directed to I M PP application 514 for further processing. 
IMPP application 514 examines the message and, using 
information contained within the packet, directs the query 10 
to presence database 516 (ST9). Presence database 
516 processes the query and, in this example, returns 
the requested information to SIP application 518 for for- 
matting of the out-bound response message (ST10). 
[0069] With the necessary SIP formatting complete, 15 
the SIP-formatted presence registration message is 
passed to an HMRT process 520. HMRT process 520 
determines to which ADCM card the SIP registration 
message packet should be routed for subsequent out- 
bound transmission (ST1 1 ). In this case, the HMRT proc- 20 
ess 520 determines that the desired outbound signaling 
link associated with the routing of the SIP registration 
message is located on ADCM 360. Consequently, the 
SIP message packet is internally routed across the IMT 
bus 31 0 to LIM 360, where it is generally received by the 25 
I/O queue process 362 (ST12). Eventually, the modified 
message packet is passed from the I/O queue 362 on to 
the IP Level 2 and Level 1 processes 364 and 366, re- 
spectively. As indicated in step ST13, the SIP-formatted 
presence registration message is then transmitted into so 
an IP network for ultimate delivery to and use by a pres- 
ence database system. 

[0070] It will be appreciated from Figure 1 2, that if the 
IMPP-formatted presence service message were a reg- 
istration request-type message, then IMPP application 35 
51 4 would examine the message and, using information 
contained within the packet, direct the registration re- 
quest to presence database 516 (ST14). In such a sce- 
nario, a response or acknowledgment message may not 
necessarily be required. 40 

Externally Mounted Presence Database System 

[0071] The embodiments of the present invention de- 
scribed in detail above can be easily extended to include 45 
a presence registration and routing node that incorpo- 
rates an externally mounted presence database system 
or server platform. One embodiment of such a presence 
registration and routing node is illustrated in Figure 13, 
and generally indicated by the numeral 600. Once again, 50 
it will be appreciated that in the particular embodiment 
presently contemplated, presence registration messag- 
es are not formulated and routed from the node, but in- 
stead presence registration takes place at or within the 
node. 55 
[0072] With particular regard to the embodiment illus- 
trated in Figure 1 3 and in a manner similar to the embod- 
iment described above, it will be appreciated that pres- 
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ence registration and routing node 600 includes a high 
speed Interprocessor Message Transport (IMT) commu- 
nications bus 310. Communicatively coupled to IMT bus 
310 are a number of distributed processing modules or 
cards including: apairof Maintenance and Administration 
Subsystem Processors (MASPs) 312, an SS7 capable 
Link Interface Module (LIM) 320, an IP capable Advanced 
Data Communication Module (ADCM) 360, and an Ex- 
ternal Presence Database Module (EPDM) 700. As fur- 
ther indicated in Figure 13, EPDM is connected to an 
external Presence Database Server platform 800 via a 
high-speed Ethernet-type connection 802. In this embod- 
iment, external Presence Database Server platform 800 
includes the actual Presence Database entity 516. With 
exception of the EPDM card 700 and external Presence 
Database Server800, all otherfunctional and operational 
aspects of the embodiment shown in Figure 1 3 are iden- 
tical to that of the embodiment shown in Figure 1 1 and 
generally described above. 

[0073] In general, an EPDM card 700 includes the da- 
tabase and database control processes necessary to fa- 
cilitate the presence registration and query handling func- 
tionality of the contemplated embodiment of the present 
invention. The EPDM 700 shown in Figure 13 is com- 
prised, in part, of an SCCP subsystem controller known 
as a Signaling Connection Routing Controller (SCRC) 
process 504, a Presence Database Manager (PDMG) 
process 51 0, and a number of Presence Database Inter- 
face (PDI) Applications generally indicated by the numer- 
al 512. Included among the PDI Applications 512 are a 
session initiation protocol (SIP) application process 518, 
an IMPP application process 514, and a presence pro- 
tocol process 51 9. The SCRC process 504 is responsible 
for discrimination of signaling messages and subsequent 
distribution of these signaling messages to an appropri- 
ate higher processing level application or function. In the 
configuration shown in Figure 13, the next highest 
processing level is represented by the PDMG process 
510. PDMG process 510 is generally responsible for de- 
termining which of the provisioned protocol-specific PDI 
Applications 512 is required process the incoming mes- 
sage packet. The PDI applications 512 are capable of 
generating or formatting protocol-specific presence serv- 
ice related response messages. Such a presence service 
response message might include, but is not limited to, a 
message that provides presence status information for 
a specific user in response to a presence status query. 
[0074] In the embodiment shown in Figure 13, EPDM 
card 700 further includes an Ethernet Controller (EC) 
process 702 which is communicatively coupled to the 
provisioned PDI applications 51 2 and also to the external 
Presence Database Server 800. More particularly, EC 
702 is coupled to a corresponding EC process 802 that 
resides on the external Presence Database Server 800. 
ECs 702 and 802 facilitate the communication of mes- 
sages between the PDI applications 512 and the Pres- 
ence Database 516. In all other respects, operation of 
the presence registration and routing node is identical to 
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that of presence registration and routing node 500 de- 
scribed above and illustrated in Figure 1 1 . 

Integrated Message Accounting And Billing Subsystem 

[0075] Shown in Figure 14 is another embodiment of 
a presence registration and routing node of the present 
invention, generally indicated by the numeral 900. With 
particular regard to the embodiment illustrated in Figure 
1 4 and in a manner similar to the embodiment described 
above, it will be appreciated that presence registration 
and routing node 900 includes a high speed Interproc- 
essor Message Transport (IMT) communications bus 
310. As in the previously described embodiments, com- 
municatively coupled to IMT bus 310 are a number of 
distributed processing modules or cards including; a pair 
of Maintenance and Administration Subsystem Proces- 
sors (MASPs), an SS7 capable Link Interface Module 
(LIM) 320, and an IP capable Advanced Data Commu- 
nication Module (ADCM) 360, and a Presence Registra- 
tion Module (PRM) 340. Further included in the presence 
registration and routing node 900 is an accounting and 
billing subsystem which is comprised of an accounting 
subsystem interface module (ASIM), generally indicated 
by the numeral 910, and an accounting server platform 
(ASP), generally indicated by the numeral 920. It will be 
appreciated that the combination of ASIM card 910 and 
ASP accounting server 920 includes the database and 
control processes necessary to achieve the accounting 
and billing functionality of the present invention. From a 
practical implementation standpoint, ASP 920 could as- 
sume the form of a Sun Workstation or similar type com- 
puting platform. It will be further appreciated that an entire 
message accounting subsystem could also be integrated 
within a presence routing and registration node. 
[0076] The ASIM card 910 shown in Figure 14 includes 
a Signaling Connection Control Part (SCCP) subsystem 
912 that is responsible for receiving and preliminary 
processing of incoming SCCP encapsulated accounting 
message packets. ASIM card 910 also includes an SCCP 
controller known as aSignaling Connection Routing Con- 
troller (SCRC) process 914 and a high-speed Ethernet 
Controller (EC) process 916. Once again, as described 
above, the SCCP subsystem 912 is responsible for re- 
ceiving and preliminary processing of incoming SCCP 
encapsulated message packets, while the SCRC proc- 
ess 91 4 is responsible for discrimination and subsequent 
distribution of messages based on information contained 
in an SCCP packet. In the case of ASIM card 910, mes- 
sages that satisfy the SCRC discrimination criteria are 
distributed or directed to the high-speed Ethernet Con- 
troller process 91 6. EC process 91 6 is in turn responsible 
for controlling the process of communicating messages, 
via an Ethernet connection to and from the associated 
ASP server 920. More particularly, ASP server 920 in- 
cludes a corresponding high-speed Ethernet Controller 
process 922 that serves as the communications interface 
between ASIM card 910 and an on-board accounting 



server manager (ASM) process 924. ASM process 924 
is responsible for the de-capsulation or removal of the 
SCCP envelope that contains the accounting message. 
The de-capsulated accounting message is then passed 

5 to an adjacent usage and measurements process 926 
where usage and measurement statistics are created 
and stored in a usage and measurements database 
(UMD) process 930, such as that shown in Figure 15. 
[0077] Usage and measurements statistics produced 

10 by such a process could include, but are not limited to, 
peg counts of messages received from a specific network 
address, a specific service provider, a specific service 
user, a specific IP socket, or a specific signaling link. 
Furthermore, information specific to the type of service 

15 requested, calling and called party information, and other 
information associated with a communication that could 
be useful in generating a bill or invoice may also be stored 
in a UMD. As shown in sample UMD process 930, in one 
simplified embodiment, each communication is identified 

20 by a transaction ID, and certain predetermined informa- 
tion associated with a communication can be stored in 
the database. It will be appreciated that the information 
contained in a UMD database could be significantly more 
or less detailed than that indicated in the example shown 

25 in Figure 15. 

[0078] In any event, such statistics could include infor- 
mation associated with the time-of-day that a message 
was received, the duration of a "call" or communication, 
general quality of service (QoS) indicators associated 

30 with a "call" or communication, information related to or 
identifying the type of service that is associated with a 
"call" or communication (i.e., broadband service related, 
call setup related, database query related, etc.). Such 
usage information could be used to bill a subscriber at 

35 different rates depending upon the type of service re- 
quested. With such capability included within a presence 
server and routing node, network operators greatly in- 
creased flexibility with regard to service-specific billing, 
without significantly increasing network OA&M require- 

40 ments. 

[0079] In order to facilitate such billing operations, ASP 
server 920 also includes a billing process 928 that is 
adapted to extract information stored by the usage and 
measurements process 926 and subsequently generate 

45 bills. Once again, information or parameters maintained 
by process 926 that may be used in the generation of 
bills could include, but is not limited to, a network address 
identifier, a service provider identifier, a service user 
identifier, an IP socket identifier, a signaling link identifier, 

50 and a service type identifier. It will be further appreciated 
that a network address identifier could include, but is not 
limited to a destination or origination SS7 point code, a 
destination or origination IP address, and a destination 
or origination domain name. Similarly, a user identifier 

55 could include, but is not limited to a calling or called party 
telephone number, and a destination or origination email 
address. 

[0080] In the particular embodiment shown, LIM card 



13 



25 



EP 1 269 764 B1 



26 



320 includes a Presence Registration Request (PRR) 
stop action process 902, that is functionally similar to the 
PRR process 328 described above. In addition to gen- 
erate, and SCCP encapsulate an accounting message 
that is subsequently passed via IMT bus 310 to ASIM 
910 of the accounting and billing subsystem. 
[0081] In a preferred embodiment, a normalized ac- 
counting message (NAM) format is employed to provide 
the necessary message information content to the asso- 
ciated accounting and billing subsystem. That is, a NAM 
formatted accounting message employs a field or record 
structure that is essentially a superset of all parameters 
of interest from all signaling, presence and instant mes- 
saging protocols of interest. As such, parameters of in- 
terest in a SIP formatted signaling message can be easily 
accommodated in a NAM accounting message, as can 
parameters of interest in an SS7 formatted signaling 
message. It will be further appreciated that the NAM for- 
mat can be periodically expanded (or revised) to accom- 
modate new or evolving signaling protocols that must be 
supported by a presence registration and routing node 
of the present invention. LIM card 320 can also be con- 
figured to simply encapsulate a copy of the received sig- 
naling message packet and forward the packet to the 
associated accounting and billing subsystem. 
[0082] With regard to the message encapsulation dis- 
cussed above, it should be appreciated that SCCP en- 
capsulation of a NAM message is not essential to the 
operation of the message accounting subsystem of the 
present invention. Other internal encapsulating protocols 
could be just as easily employed, provided that a suitably 
provisioned ASIM module is capable of receiving and 
processing the encapsulated messages. In fact, no en- 
capsulation necessarily need be performed, so long as 
the accounting message generated by a PRR type proc- 
ess can be received and generally processed by a suit- 
able configured ASIM module. 

[0083] Figure 1 6 illustrates yet another embodiment of 
a presence registration and routing node of the present 
invention, which extends the integrated accounting and 
billing subsystem concept to the routing node previously 
presented in Figure 1 1 . This new embodiment of a pres- 
ence server and routing node is generally indicated by 
the numeral 950. With particular regard to the embodi- 
ment illustrated in Figure 16 and in a manner similar to 
those embodiments described above, it will be appreci- 
ated that presence registration and routing node 950 in- 
cludes a high speed Interprocessor Message Transport 
(IMT) communications bus 310. Communicatively cou- 
pled to IMT bus 31 0 are a number of distributed process- 
ing modules or cards including: a pair of Maintenance 
and Administration Subsystem Processors (MASPs), an 
SS7 capable Link Interface Module (LIM) 320, and an IP 
capable Advanced Data Communications Module (AD- 
CM) 360, and a Presence Registration Module (PRM) 
340. Further included in the presence registration and 
routing node 950 is an accounting and billing subsystem 
which is comprised of an accounting subsystem interface 



module (ASIM), generally indicated by the numeral 910, 
and an accounting server platform (ASP), generally in- 
dicated by the numeral 920. Again, it will be appreciated 
that the combination of ASIM card 910 and ASP account- 

5 ing server 920 includes the database and control proc- 
esses necessary to achieve the accounting and billing 
functionality of the present invention. 
[0084] In the particular embodiment shown, LIM card 
320 includes a Presence Registration Request (PRR) 

10 stop action process 952, that is functionally similar to the 
PRR process 902 described above. PRR 952 is adapted 
to generate, and SCCP encapsulate, an accounting mes- 
sage that is subsequently passed via IMT bus 310 to 
ASIM 910 of the accounting and billing subsystem, where 

15 accounting and billing subsystem processing occurs in 
a manner similar to that described above. 
[0085] It will be understood that various details of the 
invention may be changed without departing from the 
scope of the invention. Furthermore, the foregoing de- 

20 scription is for the purpose of illustration only, and not for 
the purpose of limitation-the invention being defined by 
the claims. 



25 Claims 

1 . A method for updating presence information regard- 
ing an end user (402, 422, 442) in a presence server 
(410, 426, 446) database based on information de- 

30 rived from a telephony-related action, the method 
comprising: 

(a) receiving a signaling system seven (SS7) 
message at a presence registration and routing 

35 node (300, 500) in response to a telephony-re- 

lated action performed by an end user (402, 422, 
442); 

(b) in response to receiving the SS7 message, 
formulating an internet protocol (IP) message at 

40 the presence registration and routing node (300, 

500) for updating presence information regard- 
ing the end user (402, 422, 442) managed by a 
presence server (410, 426, 446); 

(c) transmitting the IP message to the presence 
45 server (41 0, 426, 446) from the presence regis- 
tration and routing node (300, 500) over an IP 
network; and 

(d) routing the SS7 message from the presence 
registration and routing node (300, 500) to ades- 

50 tination address specified in the SS7 message. 

2. A presence registration and routing node (300, 500) 
for updating presence information regarding an end 
user (402, 422, 442) in a presence server (41 0, 426, 

55 446) database based on information derived from a 
telephony-related action, the presence registration 
and routing node (300, 500) comprising: 



14 



27 



EP 1 269 764 B1 



28 



(a) a communication module (320) for receiving 
an SS7 message from an SS7 network and sub- 
sequently routing the SS7 message to a desti- 
nation address specified in the SS7 message; 
and 5 

(b) a presence server message generator (512) 
for generating a presence-server-compatible in- 
ternet protocol message (IP) for updating pres- 
ence information regarding an end user (402, 
422, 442) in a presence server (41 0, 426, 446) 10 
database, based on the SS7 message and 
transmitting the IP message to the presence 
server (410, 426, 446). 



3. The presence registration and routing node of claim 15 
2 comprising an advanced data communication 
module for encapsulating the presence-server-com- 
patible message in an I P packet and transmitting the 

IP packet to a presence server over an IP network. 

20 

4. The presence registration and routing node of claim 
2 wherein the presence-server-compatible message 
is a session initiation protocol (SIP) message. 

5. The presence registration and routing node of claim 25 
2 wherein the presence-server-compatible message 

is a presence protocol message. 

6. The presence registration and routing node of claim 

2 wherein the presence-server-compatible message so 
is an instant messaging and presence protocol (IM- 
PP) message. 

7. The presence registration and routing node of claim 

2 wherein the SS7 message is an ISDN user part 35 
(ISUP) message. 

8. The presence registration and routing node of claim 
2 wherein the SS7 message is a transaction capa- 
bilities application part (TCAP) message. 40 

9. The presence registration and routing node of claim 
2 wherein the SS7 message is a message from a 
mobile switching center (MSC). 

45 

10. The presence registration and routing node of claim 
2 comprising a presence server database (51 6) op- 
eratively associated with the presence server mes- 
sage generator (512) for receiving the presence- 
server-compatible message and for extracting the 50 
presence information in response to the presence- 
server compatible message. 

1 1 . The presence registration and routing node of claim 

10 wherein the presence server database (516) is 55 
located internal to the presence registration and rout- 
ing node (500). 



12. The presence registration and routing node of claim 
10 wherein the presence server database (516) is 
located external to the presence registration and 
routing node (500). 

13. The presence registration and routing node of claim 
2 wherein the presence server message generator 
(512) is adapted to receive presence queries, for- 
ward the presence queries to a presence server da- 
tabase (516), and receive responses from the pres- 
ence server database (516). 

14. The presence registration and routing node of claim 
2 comprising: 

(a) means for generating an accounting mes- 
sage based on at least one of the SS7 message 
received by the communication module and the 
presence-server-compatible message; and 

(b) an accounting and billing system for storing 
accounting information based on the accounting 
message. 

15. A computer program product comprising computer- 
executable instructions embodied in a computer- 
readable medium for performing steps comprising: 

(a) receiving a signaling system seven (SS7) 
message at a presence registration and routing 
node (300, 500) in response to a telephony-re- 
lated action performed by an end user (402, 422, 
442); 

(b) in response to receiving the SS7 message, 
formulating an internet protocol (IP) message at 
the presence registration and routing node (300, 
500) for updating presence information regard- 
ing the end user (402, 422, 442) managed by a 
presence server (410, 426, 446); 

(c) transmitting the IP message to the presence 
server (41 0, 426, 446) from the presence regis- 
tration and routing node (300, 500) over an IP 
network; and 

(d) routing the SS7 message from the presence 
registration and routing node (300, 500) to ades- 
tination address specified in the SS7 message. 

16. The method or computer program product of claim 
1 or claim 15 wherein the telephony-related action 
includes dialing a called party telephone number uti- 
lizing a PSTN telephone (PSTN) and the signaling 
system seven message is an IAM message. 

17. The method or computer program product of claim 
1 or claim 15 wherein the telephony-related action 
includes entering DTMF digits using a PSTN tele- 
phone handset (PSTN) after a call has been estab- 
lished, the DTM F digits forming a code for instructing 
an end office (444) to formulate the SS7 message. 
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18. The method or computer program product of claim 
1 or claim 15 wherein the SS7 message is a trans- 
action capabilities application part (TCAP) message 
containing presence information for the end user. 

19. The method or computer program product of claim 
1 or claim 15 wherein the telephony-related action 
is the activation of a mobile telephone handset and 
the SS7 message is a message for updating the sta- 
tus of the subscriber in at least one of a home location 
register (HLR) and a visitor location register (VLR). 

20. The method or computer program product of claim 
1 or claim 15 wherein formulating an IP message 
includes formulating a presence protocol message. 
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500) aus uber ein IP-Netzwerk; und 
(d) Routen der SS7-Nachricht von dem Anwe- 
senheitsregistrierungs- und Streckenknoten 
(300,500) aus an eine in derSS7-Nachrichtspe- 
zifizierte Bestimmungsadresse. 

Anwesenheitsregistrierungs- und Streckenknoten 
(300, 500) zum Updaten bzw. Aktualisieren einer An- 
wesenheitsinformation betreffend einen Endbenut- 
zer (402, 422, 442) in der Datenbank eines Anwe- 
senheitsservers (410, 426, 446) auf der Grundlage 
einer Information, die aus einer die Telefonie betref- 
fenden Tatigkeit abgeleitet ist, wobei der Anwesen- 
heitsregistrierungs- und Strekkenknoten (300, 500) 
umfasst: 



21. The method or computer program product of claim 
1 or claim 15 wherein formulating an IP message 
includes formulating a session initiation protocol 
(SIP) message. 

22. The method or computer program product of claim 
1 or claim 15 wherein formulating an IP message 
includes formulating an instant messaging and pres- 
ence protocol (IMPP) message. 

23. The method or computer program product of claim 
1 or claim 15 comprising generating an accounting 
message in response to at least one of the SS7 mes- 
sage and the IP message and forwarding the ac- 
counting message to an accounting and billing sub- 
system. 



Patentanspruche 

1 . Verfahren zum Updaten bzw. Aktualisieren einer An- 
wesenheitsinformation betreffend einen Endbenut- 
zer (402, 422, 442) in einer Datenbank eines Anwe- 
senheitsservers (410, 426, 446) auf der Grundlage 
einer Information, die aus einer die Telefonie betref- 
fenden Tatigkeit abgeleitet ist, wobei das Verfahren 
umfasst: 

(a) Empfangen einer SS7 (Signalisierungssy- 
stem Nummer 7)-Nachricht in Reaktion auf eine 
von dem Endbenutzer (402, 422, 442) durchge- 
fuhrte, das Telefonieren betreffende Tatigkeit; 

(b) in Reaktion auf das Empfangen der SS7- 
Nachricht, Formulieren einer IP (Internet Proto- 
col)-Nachricht an dem Anwesenheitsregistrie- 
rungs- und Streckenknoten (300, 500) zum Up- 
daten der Information betreffend den Endbenut- 
zer (402, 422, 442), die durch den Anwesen- 
heitsserver (410, 426, 446) verwaltet wird; 

(c) Senden der IP-Nachricht an den Anwesen- 
heitsserver (41 0, 426, 446) von dem Anwesen- 
heitsregistrierungs- und Streckenknoten (300, 



(a) ein Kommunikationsmodul (320) zum Emp- 
fangen einer SS7-Nachricht von einem SS7- 
Netzwerk und anschlieBendes Routen der SS7- 

20 Nachricht an eine in der SS7-Nachricht spezifi- 

zierte Bestimmungsadresse; und 

(b) einen Anwesenheitsserver-Nachrichtenge- 
nerator (512) zum Erzeugen einer mit dem An- 
wesenheitsserver kompatiblen Nachricht des 

25 Internetprotokolls (IP) zum Updaten der Anwe- 

senheitsinformation betreffend den Endbenut- 
zer (402, 422, 442) in der Datenbank des An- 
wesenheitsservers (410, 426, 446) auf der 
Grundlage der SS7-Nachricht und Senden der 

30 IP-Nachricht an den Anwesenheitsserver (41 0, 

426, 446). 

3. Anwesenheitsregistrierungs- und Streckenknoten 
nach Anspruch 2 mit einem weiterentwickelten Da- 

35 tenkommunikationsmodul (engl. advanced data 
communication module) zum Einbau in der mit dem 
Anwesenheitsserver kompatiblen Nachricht in ei- 
nem IP-Paket und Senden des IP-Pakets an den 
Anwesenheitsserver uber das IP-Netzwerk. 

40 

4. Anwesenheitsregistrierungs- und Streckenknoten 
nach Anspruch 2, wobei die mit dem Anwesenheits- 
server kompatible Nachricht eine SIP (Sitzungsiniti- 
ierungsprotokoll)-Nachricht ist. 

45 

5. Anwesenheitsregistrierungs- und Streckenknoten 
nach Anspruch 2, wobei die mit dem Anwesenheits- 
server kompatible Nachricht eine Anwesenheitspro- 
tokolls-Nachricht ist. 

50 

6. Anwesenheitsregistrierungs- und Streckenknoten 
nach Anspruch 2, wobei die mit dem Anwesenheits- 
server kompatible Nachricht eine IMPP (Sofortbe- 
nachrichtigungs- und Anwesenheitsproto- 

55 koll)-Nachricht ist. 

7. Anwesenheitsregistrierungs- und Streckenknoten 
nach Anspruch 2, wobei die SS7-Nachricht eine 
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ISUP (ISDN-Benutzerschnittstellen)-Nachricht ist. 

8. Anwesenheitsregistrierungs- und Streckenknoten 
nach Anspruch 2, wobei die SS7-Nachricht eine 
TCAP (Anwendungsteil fur Dialogfahigkeit)-Nach- 
richt ist. 

9. Anwesenheitsregistrierungs- und Streckenknoten 
nach Anspruch 2, wobei die SS7-Nachricht eine 
MSC (Mobilfunk-Vermittlunggszentrum)-Nachricht 
ist. 

10. Anwesenheitsregistrierungs- und Streckenknoten 
nach Anspruch 2 mit einer Anwesenheitsserverda- 
tenbank (516), die operativ mit dem Nachrichtenge- 
nerator (512) des Anwesenheitsservers fur das 
Empfangen der mit dem Anwesenheitsserver kom- 
patiblen Nachricht und fur das Abrufen der Anwe- 
senheitsinformation in Reaktion auf die mit dem An- 
wesenheitsserver kompatiblen Nachricht verbunden 
ist. 

11. Anwesenheitsregistrierungs- und Streckenknoten 
nach Anspruch 1 0, wobei sich die Anwesenheitsser- 
verdatenbank (516) innerhalb des Anwesenheitsre- 
gistrierungs- und Streckenknotens (500) befindet. 

12. Anwesenheitsregistrierungs- und Streckenknoten 
nach Anspruch 1 0, wobei sich die Anwesenheitsser- 
verdatenbank (516) auBerhalb des Anwesenheits- 
registrierungs- und Streckenknotens (500) befindet. 

13. Anwesenheitsregistrierungs- und Streckenknoten 
nach Anspruch 2, wobei der Nachrichtengenerator 
des Anwesenheitsservers dazu dient, Anwesen- 
heitssuchabfragen zu empfangen, die Anwesen- 
heitssuchabfragen an die Datenbank (512) des An- 
wesenheitsservers (51 6) weiterzuleiten und Antwor- 
ten von dem Anwesenheitsserver (51 6) aus zu emp- 
fangen. 

14. Anwesenheitsregistrierungs- und Streckenknoten 
nach Anspruch 2 mit: 

(a) einem Mittel zum Generieren einer Abrech- 
nungsnachricht auf der Grundlage der SS7- 
Nachricht, die durch das Kommunikationsmodul 
empfangen worden ist, und/oder der mit dem 
Anwesenheitsserver kompatiblen Nachricht; 
und 

(b) einem Abrechnung- und Kostenerfassungs- 
system zum Speichern der Abrechnungsinfor- 
mation auf der Grundlage der Abrechnungs- 
nachricht. 

15. Computerprogrammprodukt mit in einem Computer 
ausfuhrbaren Instruktionen, die in einem computer- 
lesbaren Medium eingebettet sind, zur Durchfuh- 
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rung derfolgenden Schritte: 

(a) Empfangen einer SS7 (Signalisierungssy- 
stem Nummer 7)-Nachricht in Reaktion auf eine 

5 von dem Endbenutzer (402, 422, 442) durchge- 

fuhrte, das Telefonieren betreffende Tatigkeit; 

(b) in Reaktion auf das Empfangen der SS7- 
Nachricht, Formulieren einer IP (Internet Proto- 
col)-Nachricht an dem Anwesenheitsregistrie- 

10 rungs- und Streckenknoten (300, 500) zum Up- 

daten der Information betreffend den Endbenut- 
zer (402, 422, 442), die durch den Anwesen- 
heitsserver (410, 426, 446) verwaltet wird; 

(c) Senden der IP-Nachricht an den Anwesen- 
15 heitsserver(41 0, 426, 446) von dem Anwesen- 
heitsregistrierungs- und Streckenknoten (300, 
500) aus uber ein IP-Netzwerk; und 

(d) Routen der SS7-Nachricht von dem Anwe- 
senheitsregistrierungs- und Streckenknoten 

20 (300, 500) aus an eine in der SS7-Nachrichtspe- 

zifizierte Bestimmungsadresse. 

16. Verfahren oder Computerprogrammprodukt nach 
Anspruch 1 oder Anspruch 15, wobei die das Tele- 
25 fonieren betreffende Tatigkeit das Anwahlen der Te- 
lefonnummer eines angerufenen Dritten unter Be- 
nutzung eines PSTN-Telefons umfasst und die SS7- 
Nachricht eine lAM-Nachricht ist. 

30 17. Verfahren oder Computerprogrammprodukt nach 
Anspruch 1 oder Anspruch 15, wobei die die Tele- 
fonie betreffende Tatigkeit das Eingeben von DTMF- 
Digits unter Verwendung eines PSTN-Telefonappa- 
rates umfasst, nachdem ein Anruf getatigt worden 

35 jst, wobei die DTMF-Digits einen Code zur Instruk- 
tion eines Endburos (444) bilden, die SS7-Nachricht 
zu formulieren. 

18. Verfahren oder Computerprogrammprodukt nach 
40 Anspruch 1 oder Anspruch 1 5, wobei die SS7-Nach- 
richt eine TCAP (Anwendungsteil fur Dialogfahig- 
keit)-Nachricht ist, die eine Anwesenheitsinformati- 
on fur den Endbenutzer enthalt. 

45 19. Verfahren oder Computerprogrammprodukt nach 
Anspruch 1 oder Anspruch 15, wobei die das Tele- 
fonieren betreffende Tatigkeit die Aktivierung eines 
mobilen Telefongerats ist und die SS7-Nachricht ei- 
ne Nachricht zum Updaten des Status des Teilneh- 
50 mers in einem Heimatstandortregister (HLR) und/ 

oder Gaststandortregister (VLR) ist. 

20. Verfahren oder Computerprogrammprodukt nach 
Anspruch 1 oder Anspruch 15, wobei das Formulie- 

55 ren einer I P-Nachricht das Formulieren einer Anwe- 

senheitsprotokoll-Nachricht umfasst. 

21. Verfahren oder Computerprogrammprodukt nach 
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45 19. 
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Anspruch 1 oder Anspruch 15, wobei das Formulie- 
ren einer IP-Nachricht das Formulieren einer SIP 
(Sitzungsinitiierungsprotokoll)-Nachricht umfasst. 

22. Verfahren oder Computerprogrammprodukt nach 
Anspruch 1 oder Anspruch 15, wobei das Formulie- 
ren einer IP-Nachricht das Formulieren einer IMPP 
(Sofortbenachrichtigungs- und Anwesenheitsproto- 
koll)-Nachricht umfasst. 

23. Verfahren oder Computerprogrammprodukt nach 
Anspruch 1 oder Anspruch 15, mitGenerierung einer 
Abrechnungsnachricht in Reaktion auf die SS7- 
Nachricht und/oder die IP-Nachricht und Weiterlei- 
ten der Abrechnungsnachricht an ein Abrechnungs- 
und Kostenberechnungs-Subsystem. 



Revendications 

1 . Procede de mise a jour d'informations de presence 
relatives a utilisateur final (402, 422, 442) dans une 
base de donnees de serveur de presence (410, 426, 
446) sur la base d'informations derivees d'une action 
Nee a la telephonie, le procede comprenant : 

(a) la reception d'un message SS7 (systeme de 
signalisation numero 7) au niveau d'un noeud 
d'enregistrement de presence et de routage 
(300, 500) en reponse a une action Nee a la te- 
lephonie effectuee par un utilisateur final (402, 
422, 442) ; 

(b) en reponse a la reception du message SS7, 
la formulation d'un message IP (protocole Inter- 
net) au niveau du noeud d'enregistrement de 
presence etde routage (300, 500) afin de mettre 
a jour des informations de presence relatives a 
I'utilisateur final (402, 422, 442) gerees par un 
serveur de presence (410, 426, 446) ; 

(c) la transmission du message IP au serveur 
de presence (410, 426, 446) depuis le noeud 
d'enregistrement de presence et de routage 
(300, 500) sur un reseau IP ; et 

(d) le routage du message SS7 entre le noeud 
d'enregistrement de presence et de routage 
(300, 500) et une adresse de destination speci- 
fiee dans le message SS7. 



a recevoir un message SS7 de la part d'un re- 
seau SS7 et a router ensuite le message SS7 
vers une adresse de destination specifiee dans 
le message SS7 ; et 

5 (b) un generateur de messages de serveur de 

presence (512) destine a generer un message 
IP (protocole Internet) compatible avec le ser- 
veur de presence de facon a mettre a jour des 
informations de presence relatives a un utilisa- 

10 teur final (402, 422, 442) dans une base de don- 

nees de serveur de presence (410, 426, 446), 
sur la base du message SS7, et a transmettre 
le message IP au serveur de presence (410, 
426, 446). 

15 

3. Noeud d'enregistrement de presence et de routage 
selon la revendication 2, comprenant un module de 
communication de donnees evolue destine a encap- 
suler le message compatible avec le serveur de pre- 

20 sence dans un paquet IP et a transmettre le paquet 
IP a un serveur de presence sur un reseau IP. 

4. Noeud d'enregistrement de presence et de routage 
selon la revendication 2, dans lequel le message 

25 compatible avec le serveur de presence est un mes- 
sage SIP (protocole de lancement de session). 

5. Noeud d'enregistrement de presence et de routage 
selon la revendication 2, dans lequel le message 

30 compatible avec le serveur de presence est un mes- 
sage de protocole de presence. 

6. Noeud d'enregistrement de presence et de routage 
selon la revendication 2, dans lequel le message 

35 compatible avec le serveur de presence est un mes- 
sage IMPP (messagerie instantanee et protocole de 
presence). 

7. Noeud d'enregistrement de presence et de routage 
40 selon la revendication 2, dans lequel le message 

SS7 est un message ISUP (partie utilisateur de re- 
seau numerique a integration de services). 

8. Noeud d'enregistrement de presence et de routage 
45 selon la revendication 2, dans lequel le message 

SS7 est un message TCAP (partie d'application de 
capacites de transaction). 



2. Noeud d'enregistrement de presence et de routage 9. 
(300, 500) destine a mettre a jour des informations 50 
de presence relatives a un utilisateur final (402, 422, 
442) dans une base de donnees de serveur de pre- 
sence (41 0, 426, 446) sur la base d'informations de- 
rivees d'une action Nee a la telephonie, le noeud 10. 
d'enregistrement de presence et de routage (300, 55 
500) comprenant : 

(a) un module de communication (320) destine 



Noeud d'enregistrement de presence et de routage 
selon la revendication 2, dans lequel le message 
SS7 est un message provenant d'un centre de com- 
mutation de services mobiles (MSC). 

Noeud d'enregistrement de presence et de routage 
selon la revendication 2, comprenant une base de 
donnees de serveur de presence (516) associee de 
maniere operationnelle au generateur de messages 
de serveur de presence (51 2) afin de recevoir le mes- 
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sage compatible avec le serveur de presence et 
d'extraire les informations de presence en reponse 
au message compatible avec le serveur de presen- 
ce. 

1 1 . Noeud d'enregistrement de presence et de routage 
selon la revendication 10, dans lequel la base de 
donnees de serveur de presence (516) est situee a 
I'interieur du noeud d'enregistrement de presence 
et de routage (500). 

12. Noeud d'enregistrement de presence et de routage 
selon la revendication 10, dans lequel la base de 
donnees de serveur de presence (516) est situee a 
I'exterieur du noeud d'enregistrement de presence 
et de routage (500). 

13. Noeud d'enregistrement de presence et de routage 
selon la revendication 2, dans lequel le generateur 
de messages de serveur de presence (512) est 
adapte afin de recevoir des demandes de presence, 
d'envoyer les demandes de presence a une base de 
donnees de serveur de presence (516), et de rece- 
voir des reponses de la part de la base de donnees 
de serveur de presence (516). 

14. Noeud d'enregistrement de presence et de routage 
selon la revendication 2, comprenant : 

(a) un moyen de generation d'un message de 
comptabilite sur la base d'au moins I'un du mes- 
sage SS7 recu par le module de communication 
et du message compatible avec le serveur de 
presence ; et 

(b) un systeme de comptabilite et de facturation 
destine a stocker des informations de compta- 
bilite sur la base du message de comptabilite. 

15. Produitde programme informatiquecomprenantdes 
instructions executables par un ordinateur integre 
sur un support lisible par un ordinateur afin d'effec- 
tuer les etapes comprenant : 

(a) la reception d'un message SS7 (systeme de 
signalisation numero 7) au niveau d'un noeud 
d'enregistrement de presence et de routage 
(300, 500) en reponse a une action Nee a la te- 
lephone effectuee par un utilisateur final (402, 
422, 442) ; 

(b) en reponse a la reception du message SS7, 
la formulation d'un message IP (protocole Inter- 
net) au niveau du noeud d'enregistrement de 
presence etde routage (300, 500) afin de mettre 
a jour les informations de presence relatives a 
I'utilisateur final (402, 422, 442) gerees par un 
serveur de presence (410, 426, 446) ; 

(c) la transmission du message IP au serveur 
de presence (410, 426, 446) depuis le noeud 



d'enregistrement de presence et de routage 
(300, 500) sur un reseau IP ; et 
(d) le routage du message SS7 entre le noeud 
d'enregistrement de presence et de routage 
5 (300, 500) et une adresse de destination speci- 

fier dans le message SS7. 

16. Procede ou produit de programme informatique se- 
lon la revendication 1 ou la revendication 15, dans 

10 lequel Taction Nee a la telephonie comprend le fait 
de composer le numero de telephone d'une partie 
appelee en utilisant un telephone PSTN (reseau te- 
lephonique public commute) et le message de sys- 
teme designalisation numero 7 estun message IAM. 

15 

17. Procede ou produit de programme informatique se- 
lon la revendication 1 ou la revendication 15, dans 
lequel Taction Nee a la telephonie comprend le fait 
de saisir des chiffres DTMF en utilisant un combine 

20 telephonique PSTN (reseau telephonique public 
commute) apres qu'un appel ait ete etabli, les chif- 
fres DTMF formant un code demandant a un central 
local (444) de formuler le message SS7. 

25 18. Procede ou produit de programme informatique se- 
lon la revendication 1 ou la revendication 15, dans 
lequel le message SS7 est un message TCAP (partie 
d'application de capacites de transaction) contenant 
des informations de presence pour I'utilisateur final. 

30 

19. Procede ou produit de programme informatique se- 
lon la revendication 1 ou la revendication 15, dans 
lequel Taction Nee a la telephonie est I'activation d'un 
combine de telephone mobile et le message SS7 est 
35 un message de mise a jour du statut de I'abonne 
dans au moins Tun d'un registre de localisation no- 
minal (HLR) et d'un registre de localisation de visi- 
ters (VLR). 

40 20. Procede ou produit de programme informatique se- 
lon la revendication 1 ou la revendication 15, dans 
lequel la formulation d'un message IP comprend la 
formulation d'un message de protocole de presence. 

45 21. Procede ou produit de programme informatique se- 
lon la revendication 1 ou la revendication 15, dans 
lequel la formulation d'un message IP comprend la 
formulation d'un message SIP (protocole de lance- 
ment de session). 

50 

22. Procede ou produit de programme informatique se- 
lon la revendication 1 ou la revendication 15, dans 
lequel la formulation d'un message IP comprend la 
formulation d'un message IMPP (messagerie instan- 
ts tanee et protocole de presence). 

23. Procede ou produit de programme informatique se- 
lon la revendication 1 ou la revendication 15, com- 
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prenant la generation d'un message de comptabilite 
en reponse a au moins I'un du message SS7 et du 
message IP et renvoi du message de comptabilite 
a un sous-systeme de comptabilite et de facturation. 
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